ITU recommendation G992.1 specifies how the maximum bandwidth which can be supported over a particular ADSL connection between a particular Remote ADSL Transceiver Unit (ATU-R) and a particular Central office or network operator ADSL Transceiver Unit (ATU-C) may be determined at the time of initiation of the ADSL connection (see G992.1 Chapter 10) and may even be periodically re-negotiated during a connection (see G992.1 Appendix II); the maximum bandwidth in fact depends upon various factors which will differ from line to line and from time to time depending on things such as the amount of electromagnetic noise present in the environment of the ATU-R, etc.
However, despite this, it is common in most practical implementations of ADSL for a network operator to offer an end user a fixed bandwidth (commonly offered values being 500 kb (kilo bits/second, 1 Mb (Mega bits/second) and 2 Mb). In such circumstances, the initiation process happens in the standard way to establish the maximum bandwidth available over the connection, but instead of then setting up the connection at that maximum setting, it is simply checked whether or not this maximum is at least equal to the contractually agreed bandwidth, and if so, then the connection is made at this agreed amount (rather than the maximum available) but otherwise the connection is just not made at all.
For IP connections passing through the Access Network via an ADSL connection to an Internet Service Provider (and thus via a Point Of Presence (POP) to the Internet), in a typical currently extant access network, there are two aggregation points. One occurs at the Digital Subscriber Line Access Multiplexer (DSLAM) (discussed above) and the other occurs at a device known as the Broadband Remote Access Server (BRAS—pronounced “Bee Raz”). The BRAS polices data flowing from ISPs through the BRAS and on through the access network towards the DSLAM and ensures that the rate at which each ISP sends data to any given end user complies with a profile which is stored in respect of each end user and includes the maximum rate at which the end user is able to receive data (which is determined by the contractually agreed connection rate, e.g. 1 Mb). Any data sent in excess of the maximum permitted rate is thrown away by the BRAS which causes the sending source to throttle back its rate of transmission (by the normal operation of the Transport Control Protocol (TCP)) until it approaches the maximum rate permitted by the BRAS.
In addition, each ISP has a maximum permitted aggregated rate at which it may send data to all of its customers at any one time, through any particular BRAS. Usually an ISP will purchase sufficient capacity to maintain a predetermined number of its end users at full capacity at any one time, which predetermined number will typically represent only a small fraction of the total number of customers to which it is connected via the respective BRAS, since only a small number of users is expected to be downloading data simultaneously via a single BRAS at any one time. If too many customers are on-line and downloading data at any one time, the BRAS will reduce the amount of data sent to each user proportionality in order to bring the total amount of data transported down to a rate which satisfies the agreement between the access network operator and the ISP.
It would be desirable to provide a system in which, instead of setting up an ADSL connection at a prearranged bandwidth or not at all, the connection is set up at the maximum bandwidth which the connection can establish. Naturally, in order to permit the full rate of data to be transmitted over the ADSL connection, it is necessary, that the respective BRAS also permits at least that rate of data for that connection to be passed through the BRAS onto the access network.
The present applicant is aware of two previously proposed approaches for achieving this in cases where the ADSL connection bandwidth is not constrained to take on only a single value. One approach, which it is believed is currently in operation in New Zealand, is to not limit the amount of data which can pass through the BRAS in respect of any one connection, but simply to enforce that data from a single ISP may not exceed a certain amount. The end user (and/or the end user's machine on behalf of the end user) may negotiate with his/her ISP after the ADSL connection has been set up such that the ISP may allow data to pass into the access network at a rate which matches that which the ADSL connection can support. Alternatively data is sent at a rate settled by the TCP protocol (i.e. if a source is sending data too quickly—for whatever reason—packets will be lost until a rate is arrived at which ceases to cause packet loss). This approach should work reasonably well on networks which are not heavily used, but in more congested networks it is very inefficient.
An alternative proposed approach is that hinted at in the DSL Forum's Technical Report No. TR-059. In this report it suggests that the “BRAS MUST be provisioned so that it does not allow traffic to flow faster than the DSL “sync” rate [which is the maximum rate which the ADSL connection can support as determined by the ATU's at the time of setting up the connection]. The BRAS MAY be provisioned with the actual DSL sync rate to accomplish this.”—see section 4.2.5.4 of TR-059 (which is on Page 21 of Version 10 of TR-059). Naturally, since TR-059 is a list of requirements rather than a description of a working system, it does not specify how this could be achieved. However, it seems to teach in the direction of communicating with the BRAS about each ADSL connection, at least every time such a connection is set up. However this solution would place a very heavy signalling burden on the access network and on each BRAS, given the current infrastructure in a typical access network for communicating with BRAS's.